home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-iplpdn-multi-isdn-02.txt
< prev
next >
Wrap
Text File
|
1993-09-02
|
20KB
|
623 lines
Draft Encapsulation Determination August 1993
INTERNET DRAFT
Expires: Februrary 16, 1994
Determination of Encapsulation of Multi-protocol
Datagrams in Circuit-switched Environments
Keith Sklower
Computer Science Department
University of California, Berkeley
1. Status of This Memo
This document is an Internet Draft. Internet Drafts are
working documents of the Internet Engineering Task Force
(IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet
Drafts.
Internet Drafts are draft documents valid for a maximum of
six months. Internet Drafts may be updated, replaced, or
obsoleted by other documents at any time. It is not appro-
priate to use Internet Drafts as reference material or to
cite them other than as a ``working draft'' or ``work in
progress.''
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil,
nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or
munnari.oz.au to learn the current status of any Internet
Draft.
2. Abstract
This document enumerates the existing means for transmitting
Internet Protocols across public data networks using cir-
cuit-mode ISDN, and other switched services. It recommends
limiting the choices to the three most common methods, from
which one can determine which method is in use by inspection
of the packets. The intention is to capture in a slightly
more formal way the level of consensus reached at the 24th -
27th IETF meetings.
3. Acknowledgements
The author specifically wishes to thank Clifford Frost and
William Jolitz for many extensive discussions on the
Sklower [Page 1]
Draft Encapsulation Determination August 1993
subject, Gary Kessler for correcting errors in the encoding
of LLC IE's, Glen Kime of Network Express for the secotion
on inverted HDLC, and more generally the IP over Large Pub-
lic Data Networks and PPP extensions working groups, whose
deliberations this memo is supposed to reflect. References
are made to earlier work by Leifer et al. [1], and Murakami
et al. [2].
4. Conventions
The following language conventions are used in the items of
specification in this document:
o MUST, SHALL or MANDATORY -- the item is an absolute
requirement of the specification.
o SHOULD or RECOMMENDED -- the item should generally be
followed for all but exceptional circumstances.
o MAY or OPTIONAL -- the item is truly optional and may
be followed or ignored according to the needs of the
implementor.
5. Introduction
The advent of Circuit-mode ISDN has provided the possibility
of much higher rates of information exchange than previously
possible over modems and voice-grade lines. We anticipate
the use of this technology to encourage ``tele-commuting''
(making it more possible for people to work effectively at
home), and to reduce the cost of data communications in
businesses having geographically dispersed sites. Other
applications, such as multi-media conferencing, are much
more economically feasible than before. The contribution by
Murakami also cites the use of ISDN to acquire additional
bandwidth for handling excess traffic in parallel with
leased lines, and more generally back-up of a failed leased
line.
Given the newness of the technology, the diversity of its
applications, and its wide availability, it is not surpris-
ing that a number of incompatible link level protocols are
coming into use for the transmission of data over ISDN
links. Examples are the use of SLIP [3] and PPP [4,5] over
asynchronous terminal adapters using V.120 [6], PPP over
synchronous terminal adapters using V.120 or directly over
the B channel via native ISDN interfaces [13], and both the
Multiprotocol Encapsulation over X.25 [7], or Mutltiprocol
Encapsulation over Frame Relay [8] directly on the B chan-
nel. There are even other examples cited in Murakami's
paper.
Sklower [Page 2]
Draft Encapsulation Determination August 1993
In this paper we recommend limiting the choice of encapsula-
tions to those described in RFC 1294 (Frame Relay), RFC 1331
(PPP), and RFC 1356 (X.25).
The contribution by Murakami suggests using out-of-band sig-
naling for negotiating the link-layer protocol and other
configuration parameters using ISDN Information Elements
such as UUI and BC. It is the experience of the members of
the IPLPDN that ISDN implementation are as yet so diverse,
the deployment of Switching System 7 so limited, and sub-
scription policies by the regional providers so different,
that user cannot depend on having these information elements
passed end-to-end. The likeliest element to be passed end-
to-end is LLC; this memo proposes a method for chosing the
link-layer protocol based on this element when available.
Where it is not available, an algorithm is proposed for
``negotiating'' the protocol by in-band exchange of data.
Other configuration parameters can be negotiated in band
using PPP, even for the Frame Relay and X.25 cases, as
described in PNMI[9].
6. Principal Recommendations
6.1. RFC 1294
6.1.1. Specific Encoding
RFC 1294 specifies the transmission of datagrams in a format
according to Q.922. As this is an HDLC framing, it is com-
pletely suitable for use on an ISDN B channel.
The RFC does not describe how the Q.922 header is generated;
it was assumed that a genuine frame relay would provide it
as a normal consequence of its operation. All other details
of the encapsulation were completely specified by this RFC.
In fact, it is possible to employ ISDN to gain access to a
Frame Relay, and when doing so packets received from it will
contain a valid DLCI. Obviously, a system communicating
with a frame relay must set the DLCI's appropriately.
When transmitting datagrams across an ISDN B-channel using
this format between systems which are not Frame Relays, such
systems MUST provide a valid DLCI header. As such, the low-
est order bit of the first byte transmitted MUST be zero.
The DLCI may be configured by prior agreement to any accept-
able value. A default DLCI value of 16 is consistent with
current ANSI recommendations (T1.617), however at some
future time when frame relay service is offered over the D
channel, the default DLCI value should be 512 (T1.618).
Sklower [Page 3]
Draft Encapsulation Determination August 1993
6.1.2. Advantages of Frame Relay Encapsulation
A primary advantage for Frame Relay Encapsulation is that
communication providers such as the Regional Bell Operating
Companies may be able to offer ISDN accessible frame relay
service which is high integrated with the voice switching
fabric.
Proponents for this method have claimed that RFC 1294 encap-
sulation is very simple to implement; in fact it is possible
to prepend a fixed header to all datagrams sent, and com-
pletely ignore the first few bytes of any datagram received.
When systems have been compatibly preconfigured, no further
state must be maintained on a per B-channel basis. This is
clearly of concern for circumstances like multiple primary
rate interfaces coming into a single router, thus poten-
tially supporting hundreds of B-Channels.
Furthermore, it is possible to start transmitting data as
soon as the circuit has been established, thereby reducing
latency. PPP and X.25, by contrast require an exchange of
packets to declare the link up. However, to be fair,
changes have been proposed to PPP suggesting that it too may
be manually configured, and in such cases may not require
the usual exchange of packets
6.2. PPP
The proponents for PPP argue that it is widely implemented,
and constructed in such a way to force interoperability.
The details of the protocol are completely specified by
RFC's 1331 and 1332, and are also applicable to any situa-
tion where synchronous transmission of data is possible.
They argue that any commercial router one procures is likely
already to have code supporting PPP, and it is flexible
enough to adapt to all the situations cited as applications
in this memo.
6.3. RFC 1356/B-Channel X.25
Systems supporting exchanging information according to OSI
conventions are required to support X.25 over the B-channel,
and RFC 1356 provides means for conveying Internet Protocols
in this situation.
7. In-Band Link Protocol Determination
The algorithm is that the caller starts transmitting data or
negotiation according to his preferred encapsulation, and
the callee just figures out what is desired by inspection of
the first correctly framed HDLC packet. If either the
caller or callee selects PPP or X.25, they will be required
Sklower [Page 4]
Draft Encapsulation Determination August 1993
to retransmit either PPP LCPs or X.25 SABM until they time
out.
7.1. Caller's Algorithm
A system wishing to exchange information using RFC-1294
encapsulation MUST transmit some packet with a valid two-
byte DLCI. The calling system MAY transmit protocol data
immediately, given suitable preconfiguration. The calling
system MAY also initiate parameter negotiation according to
PNMI, using the RFC-1294 encapsulation.
A system wishing to exchange information using PPP will
issue an LCP packet in native PPP format, according to the
requirements of RFC 1331; i.e. the first byte will be 0xff,
and the second byte will be 0x3, etc.
A system wishing to use X.25 will issue a SABM with an
address of station A, according to the OSI implementors
agreement [10].
7.2. Callee's Algorithm
The called system will wait until it has received a cor-
rectly framed and checksummed HDLC packet and inspect the
very first byte. PPP requires that the station address be
all ones (0xff). Conventional X.25 HDLC requires a station
address of either 1 or 3. The 2,3 or 4 byte DLCI Q.922 for-
mats all require that the low order bit of the first byte to
be zero. Thus, it is possible for a called system support-
ing all three methods to unambiguously determine which
encapsulation is desired and respond in the appropriate man-
ner.
In the past, many networks required that CPE that sent digi-
tal data maintain a minimum one's density. One of the com-
mon methods of achieving this was to use inverted HDLC data.
Inverted HDLC data was the simple inversion of the output of
the transmitter. Because HDLC data cannot have more than 5
ones in a row (Abort avoidance). Consequently, inverting
HDLC data guarantees no more than 5 zeroes in a row, meeting
one's density.
Even though this restriction no longer applies on B8ZS
lines, some installed equipment still use data inversion.
The following details a method which the receiver of a call
may use to discriminate between equipment using normal (non-
inverted) data and equipment using inverted data. Note that
the recommended method for both Caller and Callee is to use
normal data.
Upon call establishment, the receiver should program their
CPE to accept normal data. If a correctly-framed HDLC
Sklower [Page 5]
Draft Encapsulation Determination August 1993
packet with a correct CRC (hereafter referred to as a "good"
frame) is received, the procedures described above should be
followed. If, after 10 seconds, no "good" frame has been
received, the hardware should be reprogrammed to accept
inverted data. If a "good" packet has been received, handle
as above. Otherwise, wait 10 seconds and revert to
inverted.
Continue this as long as makes sense. One thought on total
time is that, at this point, the call has been established.
Thus, you will likely be charged for 1 minute anyway, so you
might as well try for a minute.
8. Out of Band Signaling
{Warning - Meta paragraph. At the last IETF meeting, it was
agreed that somebody would approach ANSI for obtaining a
code point for the LLC-IE byte 7 "user information layer 3
protocol" that would indicate PPP. I probably have botched
this section but I'm going to include it to make it easier
for whoever edits this next}.
8.1. Caller's Requirements
In cases where the LLC information element is available and
can be transmitted to be relied on end to end, and the sys-
tem wishes to communicate using the RFC-1294 encapsulation,
a system MUST encode the LLC-IE in the following way in his
setup message:
Sklower [Page 6]
Draft Encapsulation Determination August 1993
8 7 6 5 4 3 2 1
-----------------------------------------------------------
0 1 1 1 1 1 0 0
0 Low Layer Compatibility Octet 1
-----------------------------------------------------------
.
.
.
-----------------------------------------------------------
1 1 0 0 1 1 1 1 Octet 6
ext layer 2 ident Core Aspects of Q.922 (Frame Relay)
-or-
1 1 0 0 1 1 1 0 Octet 6
ext layer 2 ident Full Q.922 (LAPF)
-----------------------------------------------------------
1 1 1 0 1 0 1 1 Octet 7
ext layer 3 ident ISO/IEC TR 9577 (Protocol Identifi-
cation in the Network Layer)
-----------------------------------------------------------
In cases where the system wishes to exchange information
using RFC-1356/X.25 PLP/LAPB a system MUST encode the LLC-IE
in the following way in his setup message:
8 7 6 5 4 3 2 1
-----------------------------------------------------------
0 1 1 1 1 1 0 0
0 Low Layer Compatibility Octet 1
-----------------------------------------------------------
.
.
.
-----------------------------------------------------------
1 1 0 0 0 1 1 0 Octet 6
ext layer 2 ident CCITT Recommendation X.25 link level
-----------------------------------------------------------
1 1 1 0 0 1 1 0 Octet 7
ext layer 3 ident CCITT Recommendation X.25 packet level
-----------------------------------------------------------
8.2. Callee's Algorithm
If the LLC-IE exactly matches that generated by the caller's
algorithm, the system SHOULD proceed according to the encap-
sulations spelled out here. The callee MAY inspect the
first correctly framed HDLC packet to see that it matches
the encapsulation scheme described.
If the LLC-IE contains other values, the system SHOULD pro-
ceed according to the ``wait-and-see'' algorithm described
Sklower [Page 7]
Draft Encapsulation Determination August 1993
above. However, system MAY refuse the connection, or the
system MAY make the following inferences: If the User infor-
mation layer 3 protocol is 0 1 0 0 0 (ISO 8348 Connection
oriented network service), the system MAY assume that
RFC-1356/X.25 operation is requested. If the User informa-
tion layer 3 protocol is 0 1 0 0 1 the system MAY assume
that only ISO 8473 packets will be routed, (just as if an
X.25 call had been placed with a CUD of 81).
A system MAY also assume that octet 7 with a value of
0 1 1 1 0 indicates a desire to encapsulate according to
RFC-1294.
9. Interoperability Defaults and Recommendations.
It is REQUIRED that all systems wishing to exchange multi-
protocol datagrams over circuit mode ISDN implement the PPP
protocol. Such systems encapsulate packets MAY encapsulate
packets according to any of the metchods delineated here:
PPP, Frame Relay, or X.25. (Systems cannot expect to inter-
operate if they use PPP inside V.120, or transmit IP
directly inside HDLC framed packets). If a calling system
does not get a response to its initial choice of encapsula-
tion, it MUST eventually try using the PPP encapsulation.
10. Addressing Stated Requirements of Earlier Work
10.1. Leifer et al
A goal of this proposal was to be able to use bandwidth on
demand, and obtain the advantage of using multiple B chan-
nels for transmitting traffic between two hosts. There are
a number of possible ways of doing this which will be dis-
cussed at length in a separate draft.[12]
10.2. Murakami et al
A major concern of this paper was the use of out-of-band
signaling to negotiate compatible configuration parameters.
It is the contention of this author that any parameter need-
ing to be negotiated in this scheme should be able to be
done so by PNMI, and if it can't then PPP should be extended
to negotiate that parameter.
11. References
[1] Leifer, D., Sheldon, S., and Gorsline B., "A Subnetwork
Control Protocol for ISDN Circuit-Switching" IPLPDN
Working Group, Internet Draft (Expired), March 1991.
[2] Muramaki, K., and Sugawara, T., "A Negotiation Protocol
for Mutliple Link-Protocol over ISDN Circuit Switch-
ing", IPLPDN Working Group, Committee Document, May
Sklower [Page 8]
Draft Encapsulation Determination August 1993
1992.
[3] Romkey, J.L., "A Nonstandard for Transmission of IP
Datagrams over Serial Lines: SLIP." Network Working
Group, RFC-1055, June 1988.
[4] Simpson, W., "The Point-to-Point Protocol (PPP) for the
Transmission of Multi-protocol Datagrams over Point-to-
Point Links", Network Working Group, RFC-1331, May
1992.
[5] McGregor, G., "The PPP Internet Protocol Control Proto-
col (IPCP)" Network Working Group, RFC-1332, May 1992.
[6] CCITT, "Recommendation V.120: Data Communications over
the Telephone Network" Blue Book, ITU 1988
[7] Malis, A., Robinson, D., Ullman R., "Multiprotocol
Interconnect on X.25 and ISDN in the Packet Mode", Net-
work Working Group, RFC-1356, August 1992.
[8] Bradley, T., Brown, C., and Malis, A., "Multiprotocol
Interconnect over Frame Relay", Network Working Group,
RFC-1294, January 1992.
[9] Sklower, K. and Frost, C. "Parameter Negotiation for
the Multiprotocol Interconnect" IPLPDN Working Group,
Committee Document, November 1992.
[10] Boland, F., editor, "Stable Implementation Agreements
for Open Systems Interconnection Protocols: Version 2
Edition 1", NIST Workshop for Implementors of OSI,
NIST, February 1989.
[11] Internation Organisation for Standardization, "HDLC -
Description of the X.25 LAPB-Compatible DTE Data Link
Procedures", Internation Standard 7776, 1988
[12] Sklower, K., "A Multilink Proceedure for Synchronizing
the transmission of Multi-protocol Datagrams", Internet
Draft, CNRI, April 1993
12. Author's Address
[13] Simpson, W., "PPP over ISDN", Internet Draft, CNRI,
August 1993.
Keith Sklower
Computer Science Department
570 Evans Hall
University of California
Berkeley, CA 94720
Sklower [Page 9]
Draft Encapsulation Determination August 1993
Phone: (510) 642-9587
Email: sklower@cs.Berkeley.EDU
13. Expiration Date of this Draft
February 16, 1994
Sklower [Page 10]